fix(e2e): drive the new device-pairing join flow in respond.spec - #662

Why

The keyed GUI matrix has reported connect 0/6 since the workspace join model changed. Four of the handles respond.spec.ts drives no longer exist in the product:

ws-join-toggle was also the spec's "configure succeeded" signal, so fixing only the type picker would have moved the failure a few lines without unblocking a single cell.

The root cause is bigger than stale selectors. Joining is device-level now: connectWorkspace refuses a workspace this device holds no pairing for, and the agent's Connect dialog offers only the ones it does — it has no token form of its own. Every test gets a fresh isolated HOME, so nothing is ever paired and the dialog can only ever render its empty state. The spec was missing an entire step.

What changed

Product — five data-testid attributes, nothing else. No behaviour, styling or i18n change, so no version bump.

• agent-type on the Agent type trigger, agent-type-option-<slug> on each option. Picking by slug matters: leaving the default selected would build every agent as the first installed type.
• connect-ws on the Connect dialog shell, so "never opened" and "opened with nothing to offer" stay separate failures in the report.
• ws-option-<slug> on each workspace option (it only had data-active), ws-none-paired on the empty state.
• ws-pair-submit on the pairing dialog's confirm button. The code field already had a stable #quick-connect-code.

e2e

• workspace.ts gains createPairingCode() — POST /v1/workspaces/{slug}/pairing-codes, reusing the existing headers. Codes are short-lived and single-use, so a run mints its own rather than carrying one in a secret; a workspace or node token is a trusted machine credential at that endpoint, so the token the reply assertion already needs is enough. It is minted after install, so it cannot expire waiting for one.
• Step 2 now joins the workspace on the device through the same Workspaces page a user would use, then creates the instance. The pairing is asserted against getNodeStatus() (i.e. node.json) rather than against the card the page draws, so a rendering hiccup cannot read as a failed pairing.
• Step 3's success signal moves from the vanished ws-join-toggle to connect-ws.
• Step 4 becomes "pick the paired workspace"; the token form is gone.

Report dimensions are unaffected. The // 2. and // 6. markers the orchestrator reads to split install / connect / respond keep their meaning — pairing sits inside the connect phase, where a failure belongs.

Testing

• npm run typecheck — clean
• npx vitest run — 48 files, 476 tests, all passing
• e2e files typecheck standalone

Notes for the reviewer

• Radix Select options render in a portal and are briefly pointer-events: none during the open animation. If the self-hosted Windows box flakes on agent-type-option-*, wrapping that click in a toPass is the fix; it could not be reproduced locally.
• Pairing redeems against the core's configured workspaceEndpoint, while the assertions use WORKSPACE_API_BASE_URL. They default to the same host, and a mismatch surfaces plainly as "Invalid pairing code", so no extra machinery was added — but it is worth knowing.
• Not touched here: e2e/agents.ts's model table and respond.spec.ts's CREDS carry two sets of values that disagree. The former is only a fallback for spec?.model, but it reads as authoritative.

🤖 Generated with Claude Code